
                                   by
                                Jay Sage
			      June 6, 1988

     As usual, I find myself with  the deadline for this TCJ column fast
approaching, wondering how two months have passed  so  quickly.  And, as
usual, I  have  far more material that I would like to talk about than I
will have time to  put  down  on  paper  (or, should I say, disk).  This
column is probably going to be shorter than average,  just  as  the pre-
vious one  was much longer, and some of the promised discussions will be
deferred still further.  Given the reasons,  you will be understanding I
hope:  Joe Wright and I are in the process of putting the  final touches
on the new releases of ZCOM and ZCPR34!  By the time you read this, they
will definitely be available.  Even if you usually find my columns a bit
too technical  for  your  tastes,  I hope you will read on as I describe
these two exciting developments.

     I will not  describe  it  here this  time, but Bridger Mitchell has
very nearly completed code similar to NZCOM that will  run  on CP/M-Plus
systems.  At last  people with newer CP/M machines for which CP/M 2.2 is
not available will also be able to  run Z System.  And they will be able
to do it while retaining almost all of the good  features  of CP/M-Plus!


                              The New ZCOM

     Two issues ago (TCJ  #30)  I  described  the  status of the nascent
NZCOM.  Things have developed considerably since  then,  and  I  can now
provide some specific details.

     First some philosophical  comments.  This  may sound rather strong,
but Joe and I both firmly believe that NZCOM is one of the most exciting
and remarkable developments in the  history  of  microcomputer operating
systems.  With all the computers we have had experience with, the opera-
ting system  has  been a static entity.  You 'boot' up the computer, and
there you have the operating system, fixed and immutable.  Few computers
offer more than one operating system.  With  those that do, the only way
you can get a different operating system is to 'reboot', which generally
involves inserting a new boot diskette and  pressing  the  reset button.
And never  do  you  get  to define the characteristics of that operating
system.  You just take what the manufacturer deigns to let you use.

     With NZCOM the operating system  becomes  a flexible tool just like
an application program.  You can change operating systems  at  any time,
even right  in  the middle of a multiple command line sequence.  You can
do it manually, or alias scripts can do it automatically, in response to
conditions in the system!  And you can determine which Z System features
are supported.

     You can change the whole  operating  system  or  just a part of it.
Would you like a new command processor?  No problem.  With a simple com-
mand, NZCOM will load it.  No assembly  or  configuration required.  One
file fits all!  That new CCP will continue to run until you load another
one.  Want to  experiment with a new disk operating system (we are play-
ing with several exciting new ones)?  Again, no problem.  NZCOM can load
them in a jiffy.  This makes  for  a  whole new world of flexibility and
adaptability, experimentation and education.

     Need more memory  to  run  a  big application program?  Fine.  Just
load a small operating system while that  application  is running.  When
it is  finished,  go back to the big system with bells and whistles like
named directories, lots  of  resident  commands, or special input/output
facilities (such as keyboard  redefiners  or  redirection  of  screen or
printer output to disk).

     Until you try this system, it is  hard to imagine how easy it is to
do these things.  Gone are the days of  taking  source  code  (no source
code is needed), editing configuration files (you don't need an editor),
assembling (you  don't  need an assembler), and patching (you don't have
to know how to use the  arcane  SYSGEN and DDT).  Simple REL files for a
particular module can be used by anyone on  any  system.  Of  course, if
you want  to  create  custom modules of your own special design, you can
still do it, but this is no  longer required, as it used to be.  Hackers
can hack, but users can simply use!

     Joe and I are really  hoping  that  NZCOM  will open the world of Z
System to the general community, to those who have no interest in learn-
ing to assemble their own operating system or do not have  the  tools or
skills.  If you  have  been  at all intrigued by the Z System (how could
you not have been?), now is your chance to experiment.

     Getting NZCOM running is  basically  a  two-step process, with each
step remarkably easy to perform.  First you define the system or systems
you want.  This is done with the program MKNZC (MaKe  NZ-Com).  Then you
load the Z System you want using the program NZCOM.  The details are ex-
plained below.  Some  comments  of  interest to the technically inclined
are enclosed in brackets.  Feel free to skip over them.


Defining NZCOM Systems

     Here is how a  person  with  a  stock  CP/M computer would go about
getting NZCOM going.  [First technical aside:  Ironically,  those  of us
who, with great skill and hard work created manually installed Z Systems
have a  much  harder job ahead of us.  To use NZCOM effectively, we must
first strip out all the ZCPR3 code in  our fancy BIOSs and get back to a
lean, Z-less system. I just spent the good part of an evening doing that
for my BigBoard I computer (though, to be fair to my  programming exper-
tise, I should add that the hardest part was finding where I had stashed
the BIOS source code).]  For the discussion that follows, we will assume
that the files in the NZCOM package have been copied onto a working disk
in drive A.

     As we said earlier, the first  step  is to use MKNZC, an easy menu-
driven program, to specify the characteristics  of  our  Z Systems.  Its
output is a descriptor file that is used later to load the system.  What
if you  don't  know enough yet about the Z System to make those choices?
Again, no problem.  There is a  standard (or, in computer language, 'de-
fault') system defined for you already, and we will start by  making it.
We do that by entering the command line

                             A>MKNZC NZCOM

This will bring up a  menu  screen  like  the one shown in Fig.  1.  The
only difference on your system will be in the actual  addresses  for the
modules, since  they  vary from computer to computer.  Press the 'S' key
to save the configuration.  MKNZC displays  a message to the effect that
it is writing out the file NZCOM.NZC.

     [Technical aside:  Files of  type  NZC  are NZCOM descriptor files.
They are simple text files, as shown in Fig.  2.  For those  of  you who
write your own assembly language programs, you may notice a strong simi-
larity to  the  symbol  or  SYM  file produced by an assembler or linker
(yep, identical).  The symbols in this file define all the necessary pa-
rameters of the system to be created.]

     From the values in Fig.  1, you  can  see that the default Z System
offers every feature available.  When this system is running  later, the
TPA (transient  program  area,  the memory available for the application
programs that do your real  work)  will  be 49.0k bytes.  This value, of
course, is for my computer; as they say,  "yours  may  vary."  A  'k' or
kilobyte is  actually  1024  bytes,  so  this  is really 50,176 bytes or
characters.  The original CP/M system, by  the  way, had a TPA of 54.25k
bytes, so we are paying a cost of 5.25k bytes for  this spare-no-expense
Z System.  As  luxurious  and opulent as this system is, it still leaves
plenty of TPA for most application programs.

     Sometimes, however, we have  an  application program that is really
hungry for memory.  Database managers, spread  sheets,  and  C compilers
often fall  into this category.  So does the new WordStar Release 4.  We
will now use MKNZC to define  a  minimum  Z System for when we run those
applications.  To give this version the name MINIMUM, enter  the command

                            A>MKNZC MINIMUM

When the menu comes up, press key  '4'.  You will be asked to define the
number of records (128-byte  blocks)  to  allocate  to  the input/output
package or  IOP.  Enter  '0' and press return.  Similarly reduce to zero
the allocations for  the  resident  command  package (RCP), flow command
package (FCP), and named directories register (NDR).  You  will  be left
with the  screen  shown  in  Fig.  3.  Press  the  'S'  key  to save the
definition of this minimal Z  System  in the descriptor file MINIMUM.NZC
[shown in Fig.  4 for the technically inclined].

     Notice that the TPA  has  grown  to  53.25k,  only 1k less than the
original CP/M system.  Even with this meagre Z System,  costing  only 1k
of TPA, you get the following features (and more):

        multiple commands on a line
        the alias facility that provides automatic command se-
                uence generation
        automatic, user-defined search path for COM files
        extended command processing (ARUNZ, described in TCJ
                #31, for example)
        error handling that tells you what's wrong with a bad
                command and allows you to correct it
        shells (menu systems, command history shell for saving
                and recalling old commands, file-maintenance
                shells, etc.)
        terminal-independent full-screen operation via Unix-like
                TCAP (terminal capabilities descriptor)

     These are only two of a wide variety of possible Z Systems.  As you
gain experience with NZCOM, you  can  fine  tune the definitions to meet
all of your needs.  For my BigBoard I computer, I have defined four sys-
tems.  Two of them, called FULL and TINY, have the features shown in the
two examples here. A third one is called SMALL.  Not quite as diminutive
as TINY, it sacrifices an additional 0.5k of TPA to retain the flow com-
mand package (FCP), which is so valuable  in  providing  high  levels of
command automation.  Even  my voracious application programs can usually
get by under this system.

     Finally, I have a system called NORMAL, which, as the name implies,
is the one I use most of  the  time.  It is the same as FULL but without
an IOP.  The most common use for an IOP is  to  run  keyboard redefiners
like NuKey.  Most  people  like  this feature, but splendid as NuKey is,
for some reason my  style  does  not  find  much use for keyboard macros
(I've become a rather skillful typist and can generally type faster than
I can think of moving my finger to a special key), so  I  generally omit
the IOP and gain 1.5k of TPA.


Loading the NZCOM Systems

     Having defined the systems above, we can now fire them up even more
easily.  For the default NZCOM  system,  just enter the following simple
command:

                                A>nzcom

With no argument after  the  command  name,  NZCOM  will load the system
defined with the name NZCOM.  As it does this,  you  will  see  a signon
message on the screen, followed by a series of dots, each one indicating
that another  module has been loaded.  [Technical aside:  If you want to
see more precisely what is  going  on,  just  add the option "/v" to the
command to select verbose mode.  You  will  then  get  a  screen display
something like  that shown in Fig.  5.  I'll have more to say about what
all this means a little later.]

     After NZCOM starts running, it executes the START.COM program. This
is usually an alias command,  a  program that simply passes another more
complex command line on to the command processor. I will not explain the
details of START here, but after it finishes, Z System  will  be  up and
running, waiting for your commands.


How NZCOM Works
---------------
     This section is for the technically inclined, so if that's not you,
pretend there are square  brackets  around  this  whole section and skip
ahead to the next section.  Here we are going to  explain  what  some of
those verbose-mode  messages  mean and what NZCOM is doing to create the
system on the fly.

     First NZCOM loads  the  descriptor  file  into memory.  Among other
things, this file has the information about which system modules to load
and to what starting addresses.  The first module loaded is  the command
processor.  It is loaded from the file NZCPR.REL, which has the code for
the command processor (ZCPR34) in so-called relocatable form.

     There is some very  interesting assembly/linkage razzle-dazzle that
goes on here.  With the REL files one usually plays with, only  the run-
time execution  address of the code is unknown at assembly time and must
be resolved by  the  linker.  Things  are  much trickier here.  When the
command processor code was assembled,  not  only  was  its  own run-time
starting address unknown, but the addresses of various other system com-
ponents, such  as the message buffer and multiple command line, to which
it refers in countless places, are also unknown. Since there is no fixed
relationship between the addresses of  the  CCP and these other modules,
there is no way to define the addresses using equates in the code.

     Put another way, when  NZCOM  converts NZCPR.REL into actual object
code, it must resolve not only the calls and jumps and  data  loads that
refer to  other  locations  in the command processor but also those that
refer to the other system modules.  Fortunately, advanced assemblers and
linkers -- including those from  SLR  Systems  and a ZAS follow-on under
development by Alpha -- already have a mechanism to handle this problem.
It was Bridger Mitchell who recognized how this mechanism,  called named
common, could accomplish what was needed here.

     When code with symbols in named common is assembled, the correspon-
ding bytes in the resulting .REL file are marked not only for relocation
but for relocation with respect to a specific common block.  The SLR as-
semblers support up to 12  named common blocks.  NZCOM contains very so-
phisticated linking code that resolves the references to  data  items in
the common  blocks,  the addresses of which it gets, naturally, from the
NZC descriptor file.

     Fig.  6 shows a partial  listing  of  the  file NZCMN.LIB, which is
referenced in a MACLIB statement in each  module  assembled  for  use by
NZCOM.  Seven named  common  blocks are defined:  _BIOS_, _ENV_, _SSTK_,
_MSG_, _FCB_, _MCL_, and  _XSTK_  for the CBIOS, environment descriptor,
shell stack, message buffer, external file control block,  multiple com-
mand line buffer, and external stack, respectively.  Note that no common
blocks are defined for the RCP, FCP, or NDR. References to these package
must be  made  indirectly  at run time, using data obtained from the en-
vironment descriptor in memory.

     How does the NZCOM loader figure out that the file NZCPR.REL is the
command processor?  You might think that  it  uses the name of the file,
but, in fact even if you had a  copy  of  it  called  MYNEWCP.REL, NZCOM
would be  able  to  load it just as well.  The answer is that the source
code contains the directive

                              NAME ('CCP')

which gives the REL file an  internal module name.  It is this name that
NZCOM uses to determine what kind of module the code represents.

     After the command processor is loaded, the other modules are loaded
in succession in similar  fashion,  except for two.  The named directory
file NZCOM.NDR is a file that you can make or change  with  the standard
utility programs  MKDIR  or EDITNDR/SAVENDR.  There is nothing in an NDR
file that requires relocation at all.  The same is true for the Z3T ter-
rminal descriptor (TCAP)  file.  It  can  be  created using the TCSELECT
utility.

     When all the loading is done,  a  copy of the command processor ob-
ject code is written out to a file called NZCOM.CCP.  This file  is used
for subsequent warm boots, since we obviously cannot warm boot from what
is on  the  system tracks of the disk (the Digital Research command pro-
cessor is still there, after all).  At this point we can resume the non-
technical discussion.

Changing NZCOM Systems
----------------------
     Now that you have Z System  running,  you can start to work with it
and learn about it.  I am not going to discuss Z System in general here;
the subject is much too extensive.  One thing you can do is  to  get out
your back  issues  of  TCJ  and  experiment  with the programs described
there.  Another is to buy the "Z  System User Guide" published by Alpha.
That book describes the Z System from a  less  technical  point  of view
than Richard Conn's "ZCPR3, The Manual," also published by Alpha.

     What I would like to discuss  now  is  some of the ways you can use
the dynamic capabilities  of  NZCOM.  First  we  will  describe  how you
change the  entire  operating system.  For these examples we will assume
that you have been doing work  in various directory areas on your system
and that you have set up named directories.  Let's say you  are  in your
dBase II  area  now.  Since you know that dBase II needs a lot of memory
to run efficiently (or should I say 'tolerably,' since it never runs ef-
ficiently!) and since (unlike  WordStar  4,  for example) it cannot make
use of any Z System features anyway, you want to load the minimum system
we created earlier.  You can probably guess what the command is:

                         B2:DBASE>nzcom minimum

     [More technical stuff:  Fig.  7 shows  the screen display you would
get with the "/v" verbose option on this command.] For the  minimum sys-
tem NZCOM  loads  only  a  command processor, disk operating system, and
virtual BIOS.  The other  system  segments disappear.  This includes the
NDR or named directory register, so the prompt changes to

                                  B2>

The START alias does  not  run  this  time.  It  runs only when NZCOM is
loaded from a non-NZCOM system (such as CP/M).

     In general, when loading a new version of the operating system from
another that is currently  running,  NZCOM  loads  only the modules that
must be loaded, either (1) because they did not exist before or  (2) be-
cause they are now at a different address or have a different size.  For
example, when  I  load  my  FULL system from the NORMAL system to add an
IOP, only the CCP, DOS, BIOS,  and  IOP  are loaded, since the RCP, FCP,
and NDR are in the same place as before and  have  the  same size.  When
modules do have to be loaded, files with the default names shown in Fig.
5 are  used.  Later  we will discuss how you can load modules with other
names.

     There are a number of system  modules that never change in the pre-
sent version of NZCOM.  (Yes, like the famous Al Jolson lines, you ain't
seen nothin' yet!)  These include  the  environment  descriptor, message
buffer, shell stack, path, wheel byte, and multiple command line buffer.
With the  exception  of  module addresses in the environment descriptor,
data in these fixed  system  modules remain unaffected.  This means that
if you had selected an error handler, for example, or a shell such  as a
command history  shell,  they  will still be in effect after a change of
system.

     Because the multiple command  line  buffer is preserved through the
load of a new system, you can include NZCOM commands as part of multiple
command sequences, alias scripts, and  shell  (MENU,  VMENU,  or ZFILER)
macros.  Thus, for example, you could have entered the command:

                   B2:DBASE>nzcom minimum;dbase etc.

In this case the  operating  system  would  have changed, and then DBASE
would have started running.  I will not go  into  the  technical details
here, but there are ways to write an alias script, which might be called
DB, that  would  check  to see if the minimum system was already running
and, if not, automatically load it before invoking DBASE.

     Nothing says the  operating  system  can  change  only  once in the
course of a multiple command line.  You might  have  alias  scripts that
change to  a minimum system, run a specific command, and then reload the
normal system  again.  There  is  a  time  penalty  associated with this
(though very little if you have the NZCOM files on a RAM disk),  but the
result is  that  the application program sees a big TPA while it is run-
ning, but you always see a nice, full-featured Z System.

     NZCOM does not even insist that  you stay in Z System.  On the con-
trary.  On a cold load from CP/M it will build (if it does not exist al-
ready) a program called NZCPM that, when run from Z System, will restore
the original CP/M system.

     [Technical aside:  Even if you need absolutely every available byte
of TPA, you can  still  automate  the  process.  You  can use the submit
facility to run a batch job that exits from Z System  entirely,  runs an
application under plain CP/M, and then returns to Z System.  You do have
to observe  some  precautions.  For  example, you have to make sure that
all command lines in the batch file  that will execute while Z System is
not in effect are valid CP/M commands.  Once the  batch  script  has re-
loaded reloaded  Z  System  using the NZCOM command, it can resume using
appropriate Z System commands,  including  multiple  commands on a line.

     Another factor to bear in mind is that NZCPM returns you to CP/M in
drive A user 0 no matter where you were when  it  executed.  Since ZCPR3
(starting with  version  3.3)  writes  its  submit  file to directory A0
rather than the current directory,  there  is no problem with continuing
operation of the batch file under CP/M.  However, when you  reload NZCOM
(it will  be  a  cold  load, including execution of START), you will not
automatically be back in your original directory.  End aside.]


Changing Parts of the System

     The NZCOM command is  not  limited  to  loading whole new operating
systems; with a slightly different syntax it  can  also  load individual
system modules,  rather  like  the LDR program in a manually installed Z
System.  There are two important differences, however.

     The first is that NZCOM loads code modules (IOP, RCP, and FCP) from
REL files rather than from absolute  files such as SYS.FCP or DEBUG.RCP.
Absolute files can still be loaded using LDR,  but  this  is undesirable
under NZCOM,  since the addresses of the modules may change as different
systems are loaded.  NZCOM has the advantage  of using a single REL file
no matter which system it is being loaded  into.  In  the  future, RCPs,
FCPs and IOPs will be distributed in REL form instead of (or in addition
to) source  code  form.  The  .REL  file is much smaller and can be used
without knowing how to assemble the code.

     The second difference is that NZCOM can load command processors and
disk operating systems as well.  This makes  it very easy to change ver-
sions of the command processor (with or without security or named direc-
tory or submit support, for example) or to  experiment  with alternative
DOSs, such as Z80DOS or P2DOS.  This will be a real boon to the develop-
ment of new operating system components, since one can test new versions
so easily and quickly.

     For convenience, NZCOM can also load named directory files (of type
NDR) and terminal descriptor files  (of  type Z3T).  This is so that you
do not have to have LDR.COM on your disk.  On an NZCOM system, LDR  is a
dangerous command,  since  it  does  not have safeguards against loading
absolute system components to addresses  for  which they were not assem-
bled.  With an NZCOM system, you should remove LDR.COM  from  your disk.


Other NZCOM Features
--------------------
     There are many more things  that  could  be said about NZCOM that I
will save for another time.  There is just one more that I want  to men-
tion now,  and that is the extra "Custom Patch Area" that can be defined
with MKNZC (see Fig. 1).  This  option  in MKNZC allows one to establish
an area in protected memory just below the CBIOS  (custom  BIOS  or real
BIOS). This area can be used by various operating system extensions that
one wants to preserve from one NZCOM system to another.

     Because of the techniques it  uses  for  patching the Z System onto
CP/M, NZCOM will not work when a resident system extension (RSX) is pre-
sent.  Thus, for example, you cannot run NZCOM from inside a  ZEX script
or if  DateStamper  or  BYE  is active in low memory (if they are loaded
above the CBIOS, there is  no  problem).  I am presently using the patch
area for DateStamper.  With NZCOM you can effectively have an above-BIOS
version of DateStamper without having to move your BIOS down.

     I am also planning  to  experiment  with  putting BYE in the custom
patch area.  I think this can be made to work, and it would permit NZCOM
to be used on my Z-Node (and I mean used actively -- so  that  the NZCOM
system can be changed even from a remote terminal!).

     There are special facilities in NZCOM that I do not have the energy
to explain now whereby information  about a currently running system can
be extracted before the new system has been loaded and used  to initial-
ize the new system just before NZCOM turns over control to it.  This al-
lows an RSX's hooks into the operating system to be maintained.


                            ZCPR Version 3.4

     Now let's turn to the  subject  of  ZCPR version 3.4, which will be
released along with NZCOM.  Z34, as I will refer to it, is much  more an
evolutionary step  from  Z33  than Z33 was from Z30.  There are four new
features worth pointing out.


Type-4 Programs

     The most important and exciting  enhancement is the introduction of
what is called the type-4 program.

     With Z33, I added support for  a  new  kind of program to run under
ZCPR3.  Programs designed to take advantage of the  special  features of
the Z System have, at the beginning of the code, a special block of data
called the  Z3ENV header.  This header identifies the program as a ZCPR3
program and contains the  address  of  the ZCPR3 environment descriptor,
where all the information necessary to find out about the  Z  System fa-
cilities is  available.  It  also  contains a type byte.  Conventional Z
System programs were of  type  1.  (Type-2  programs are similar but ac-
tually have the entire environment  desciptor  in  the header.  Programs
of this  type  are  extremely  rare.  In some senses they are a holdover
from ZCPR2 and now obsolete.)

     For the new type-3 program I added an additional datum in the Z3ENV
header:  the starting address for which  the  code had been assembled or
linked.  The command processor  automatically  loads  the  file  to that
address before transferring control to it.

     Type-3 programs are  usually  linked  to  run  in  high memory (for
example, 8000H or 32K decimal) where they  do  not  interfere  with most
data or  code  in  the  TPA.  Programs  that  run  as  extensions of the
operating system  (viz.  history  shells,  extended  command processors,
transient IF processor)  or  as  the  equivalents  of  resident programs
(viz. ERA.COM,  REN.COM,  SAVE.COM) are particularly suitable for imple-
mentation as  type-3  programs.  One  cannot  always  foresee when these
programs will be invoked, and it is nice if the  contents  of  memory at
the bottom of the TPA are not affected when they do run.

     With type-3 programs  one  must  choose  in  advance the address at
which they will run.  If the address  is  too  high,  there  may  not be
enough room  for  them  to load, and if too low, they are more likely to
interfere with  valuable  TPA  contents.  In  most  situations  it would
clearly be preferable if the program could  be  loaded  automatically as
high as  possible  in  memory.  I thought of this from the beginning but
compromised on the type-3 construct because it was so easy to code.

     Joe Wright was not  satisfied with this  compromise.  He soon wrote
an initial version of the type-4 program, which does  relocate automati-
cally to  the  top  of memory.  With a lot of cooperation between us, we
have honed it to the point  where  it functions very nicely and does not
add very much code to the command processor.

     Because type-3 programs run at  a  fixed address, albeit not neces-
sarily 100h, they can be assembled and linked in the usual  fashion, and
the program  files  contain actual binary object code.  Type-4 programs,
on the other hand, must be  relocatable  by the command processor at run
time.  Thus object code alone is not sufficient.

     One possibility  would be  to use a .REL file directly.  This would
have been very convenient, but the code required to load a .REL  file is
far too  complex to include in a command processor running in a 64K mem-
ory segment.  There is a  less  familiar  relocatable type file known as
a .PRL (Page ReLocatable) file that, because it restricts the relocation
to page boundaries (and other reasons), is much easier to relocate.

     A PRL file consists of three  parts.  The middle part is a standard
code image for execution at 100h.  After this comes what is called a bit
map, where, for each byte in the code image, there is a bit of 0 or 1 to
tell whether that byte must be offset for execution at a different page.
The bit map is one eighth the length of  the  code  image.  Finally, one
page (256  bytes) at the beginning of the file serves as a header.  This
header contains information about the  size  of  the program so that the
code that loads it can figure out where the  object  code  ends  and the
bit map begins.

     In the type-4 program, this header  is extended to include the code
necessary (1) to calculate the highest address in  memory  at  which the
program can  be  loaded  and  (2) to perform the code relocation to that
address using the bit  map.  The  way  this  is accomplished is somewhat
intricate.

     The command processor loads  the  first  record  of the type-4 file
into the temporary buffer at  80H  as  usual  to  determine  the program
type.  If it is type 4, the CCP then calls the code in the header.  That
code calculates  the  load address and then (this clever idea was Joe's)
calls the command processor back  to  load  the program code and bit map
into memory at the proper address.  When this call is complete  and con-
trol returns  to the header code, it then performs the relocation of the
code image at the execution address in memory.  Only then is control re-
returned to the command  processor  for  initialization and execution of
the program.

     The result of this tricky scheme is that most of the type-4 support
code that would otherwise have been required in the command processor is
in the header instead (this was  my contribution to the type-4 concept).
Since a PRL file has a two record header anyway (almost all of  which is
otherwise empty), you get to add this code for free.

     Joe pointed out to me  some dangers with my type-3 construct.  Sup-
pose a type-3 program designed to run at 8000H is somehow loaded to 100h
instead. Any attempt to execute it is likely to have less than desirable
consequences, to put it mildly.  This was not a serious  problem  with a
normal (at  the  time) ZCPR33 system.  Since the command processor would
automatically load the type-3  program  to  the correct address, it took
some deliberate action by the user to create the dangerous situation de-
scribed.  Of course, the poor fellow still running ZCPR30 who decided to
try out a type-3 program...

     However, now that NZCOM is here,  the  user may very well decide to
drop back into CP/M from Z System to perform some tasks.  In this situa-
tion, a type-3 program is a live weapon, just  waiting  to  blow  up the
system.  The type-4 program poses a similar danger.

     We have come up with two defense strategies. One can be implemented
in the program itself.  There is  code (TYP3HDR1.Z80) that can be placed
at the beginning of a type-3 program (based on ideas  conceived indepen-
dently by  Bob  Freed  and Joe Wright) that will verify that the code is
running at the proper address.  This part of the code is, as it must be,
address independent (it uses only  relative jumps).  If the load address
is found to be wrong, a warning message is displayed and control  is re-
turned to  the command processor before any damage can be done.  This is
the friendlier method, but it makes the programs longer.

     The second defense method does not  impose any overhead on the pro-
gram code.  It is easier to use than the other method and it  can gener-
ally be  patched  into  existing type-3 programs in object form.  It can
also be applied with type-4 programs,  for which the first method cannot
be used (type-4 files begin with a relocation header and  not  with pro-
gram code,  and  the system must be prevented from trying to execute the
header when the program is invoked under CP/M).

     With this method, one places a  byte  of C7H, the RST 0 instruction
opcode, at the beginning of  the  file.  Execution  of  this instruction
causes a  call  to  address 0, which induces a warm boot.  This behavior
may be puzzling to the user, but at least it does no damage.  How, then,
will such a program ever execute?  The  answer is that ZCPR34 checks the
first byte of a type-3 program to see if it is  a  C7H.  If  it  is, the
command processor replaces it with a C3H, the JP instruction opcode.  To
take advantage  of  this  method, the program code must begin with a "JP
START" instruction in which the JP is replaced by RST 0 (note:  you can-
not use JR START instead).  The  proper assembly language source code is
illustrated in Fig. 8.  Note that the replacement of the RST 0  by  a JP
is not  required  with a type-4 program since the header (which is where
this construct appears) is never  intended  to be executed as a standard
program, even under Z34.


The Extended Environment Descriptor and the Drive Vector
--------------------------------------------------------
     The definition of the  ZCPR3  environment descriptor has been modi-
fied and extended.  I will not go into all the details here, but  I will
describe the main changes.

     First, to make some space available for additional important infor-
mation, the extended ENV eliminates  definitions for all but one console
and one printer.  Eventually there will be a tool (utility program) that
allows interactive or command-line redefinition  of  the characteristics
of these  single devices so that you will actually have more rather than
less flexibility.

     The extended ENV will now  contain  the  addresses and sizes in re-
cords of the CCP, DOS, and BIOS (actually, the size of the  BIOS  is not
included).  This information  has  been  added  to deal with problems in
some special operating system versions  where  the CCP and/or DOS do not
have their standard sizes of 16 and 28 records respectively, such  as in
the Echelon  Hyperspace  DOS for the DT-42 computer.  Future versions of
NZCOM, which will support variable CCP, DOS, and BIOS modules, will also
need this.

     Finally, a long  needed  feature  has  at  last been implemented; a
drive vector.  The maximum-drive value in the ENV was not adequate  in a
system with  non-contiguous  drives (A, B, and F, for example).  Now you
can tell the system exactly which drives you have on the system, and the
command processor will do its  best to prevent references to nonexistent
drives.


Ever More Sensible Named Directory Security
-------------------------------------------
     With Z33 I made it possible  to  refer by drive/user (DU) to direc-
tories beyond the range specified by the maximum drive and  maximum user
values in the environment provided the directory area had a name with no
assword. It seemed only reasonable that if a user could access the drive
by name, he should be allowed to access it by its equivalent DU as well.

     The converse situation, however, was not handled according to simi-
lar logic.  Suppose  the  maximum  user  was 7 but there was a password-
protected named directory for user  6.  Under  Z33 one had the anomalous
situation that the user could refer freely to the directory using the DU
form but would be pestered for the password if he used the  (DIR) named-
directory form.  This just didn't seem reasonable, and Z34 has corrected
this.


Extended ECP Interface
----------------------
     With Z34 I have added an additional option similar to BADDUECP. The
BADDUECP option allows directory-change  commands  such  as NAME: or DU:
that refer to illegal directories to be passed on to  the  extended com-
mand processor (ECP) instead of directly to the error handler. On my own
Z-Node, for  example, I use the ARUNZ extended command processor to per-
mit references to reasonable facsimiles to the actual directory names to
work via alias scripts.

     With Z33 attempts to execute  a command containing an illegal wild-
card character or with an explicit file type would be flagged  as errors
and passed  directly  to the error handler.  With Z34 one has the option
(via the option BADCMDECP) to pass these forms of bad command to the ex-
tended command processor as well.

     Here are a couple of examples of  how this feature can be used with
the ARUNZ extended command processor. First, one can enter the following
script into the alias definition file ALIAS.CMD:

                               ?  help $*

Now when a user enters the command  "?", he will get the help system in-
stead of an error message telling him that he entered a bad command.

     You can also use this facility to allow further shorthand commands.
 With the script definition:

                 DIM.Z3T ldr dim.z3t (or nzcom dim.z3t)

Now you can load the dim-video  TCAP  for your system simply by just en-
tering the name of the TCAP file.  Using wildcard specifiers in the name
of the alias script you can make any command with a type of Z3T load the
corresponding TCAP file.  Similarly, entering the name of a library (for
example, LBRNAME.LBR) on the command line could automatically invoke VLU
on that library.  The same concept would allow one to enter the  name of
a source-code  file (for example, THISPROG.Z80 or THATPROG.MAC) to auto-
matically invoke the appropriate assembler (Z80ASM/ZAS or SLRMAC/M80 for
these two examples).

     This feature opens another whole dimension for experimentation, and
I am sure that users will come up  with all kinds of new ways to use it.
PLEASE NOTE:  if this feature is implemented,  you  cannot  use  the old
version of  ARUNZ  that  I so painstakingly documented in my last column
(alas, barely born  and  already  obsolete).  Previous versions of ARUNZ
used '?' and '.' for special purposes.  Those characters  were carefully
chosen because they could never appear in command names passed to ARUNZ,
but now  they  can!  Therefore,  in version 0.9H of ARUNZ I have changed
these characters to  '_'  (underscore)  instead  of  '?' and ',' (comma)
instead of '.'.

     That's it for this  issue,  I'm  afraid.  I  still  didn't get to a
discussion of defects in the shell coding for WordStar 4  (I  hope these
will be  corrected in version 5, which is apparently really in the works
at this time).  My discussion of  the  ZEX in-memory batch processor and
the improvements I have been making to it will also have  to  wait still
longer.  However, MicroPro has repeatedly said there will be no WordStar
version 5 for CP/M.

------------------------------------------------------------------------

        1.*     Command Processor       CCP     BD00          16 Records
        2.*     Disk Operating System   DOS     C500          28 Records
        3.*     NZ-COM Bios             BIO     D300           2 Records

        4.      In/Output Processor     IOP     D400          12 Records
        5.      Resident Command Proc   RCP     DA00          16 Records
        6.      Flow Control Processor  FCP     E200           4 Records
        7.      Named Directory  Reg    NDR     E400          14 Names

        8.*     Environment Descriptor  ENV     E500           2 Records
        9.*     Shell Stack             SHS     E600           4 Entries

        P.      Custom Patch Area       PAT     0000           0 Records
                Customer's CBIOS        TOP     E800

                        Effective TPA size 49.0k

        * Items 1, 2, 3, 8 and 9 are not changeable in this version.

        Selection: (or <S>ave or <Q>uit) _


Figure 1.  Screen displayed by  the  MKNZC  program when run under CP/M.
This is the standard or default system definition.

------------------------------------------------------------------------

E806 CBIOS      0080 ENVTYP     E6F4 EXPATH    0005 EXPATHS  DA00 RCP
0010 RCPS       D400 IOP        000C IOPS      E200 FCP      0004 FCPS
E400 Z3NDIR     000E Z3NDIRS    E700 Z3CL      00CB Z3CLS    E500 Z3ENV
0002 Z3ENVS     E600 SHSTK      0004 SHSTKS    0020 SHSIZE   E680 Z3MSG
E6D0 EXTFCB     E7D0 EXTSTK     0000 QUIET     E6FF Z3WHL    0004 SPEED
0010 MAXDRV     001F MAXUSR     0001 DUOK      0000 CRT      0000 PRT
0050 COLS       0018 ROWS       0016 LINS      FFFF DRVEC    0000 SPAR1
0050 PCOL       0042 PROW       003A PLIN      0001 FORM     0066 SPAR2
0042 SPAR3      003A SPAR4      0001 SPAR5     BD00 CCP      0010 CCPS
C500 DOS        001C DOSS       D300 BIO       0000 PUBDRV   0000 PUBUSR

Figure 2.  For the technically inclined, this is a listing  of  the con-
tents of the NZCOM.NZC system descriptor file produced by MKNZC.

------------------------------------------------------------------------
        1.*     Command Processor       CCP     CE00          16 Records
        2.*     Disk Operating System   DOS     D600          28 Records
        3.*     NZ-COM Bios             BIO     E400           2 Records

        4.      In/Output Processor     IOP     0000           0 Records
        5.      Resident Command Proc   RCP     0000           0 Records
        6.      Flow Control Processor  FCP     0000           0 Records
        7.      Named Directory  Reg    NDR     0000           0  Names

        8.*     Environment Descriptor  ENV     E500           2 Records
        9.*     Shell Stack             SHS     E600           4 Entries

        P.      Custom Patch Area       PAT     0000           0 Records
                Customer's CBIOS        TOP     E800

                        Effective TPA size 53.25k

        * Items 1, 2, 3, 8 and 9 are not changeable in this version.

        Selection: (or <S>ave or <Q>uit) _


Figure 3.  Screen displayed by  the  MKNZC program after eliminating the
IOP, RCP, FCP, and NDR modules in order to define  a  minimal  Z System.

------------------------------------------------------------------------

E806 CBIOS     0080 ENVTYP     E6F4 EXPATH    0005 EXPATHS   0000 RCP
0000 RCPS      0000 IOP        0000 IOPS      0000 FCP       0000 FCPS
0000 Z3NDIR    0000 Z3NDIRS    E700 Z3CL      00CB Z3CLS     E500 Z3ENV
0002 Z3ENVS    E600 SHSTK      0004 SHSTKS    0020 SHSIZE    E680 Z3MSG
E6D0 EXTFCB    E7D0 EXTSTK     0000 QUIET     E6FF Z3WHL     0004 SPEED
0010 MAXDRV    001F MAXUSR     0001 DUOK      0000 CRT       0000 PRT
0050 COLS      0018 ROWS       0016 LINS      FFFF DRVEC     0000 SPAR1
0050 PCOL      0042 PROW       003A PLIN      0001 FORM      0066 SPAR2
0042 SPAR3     003A SPAR4      0001 SPAR5     CE00 CCP       0010 CCPS
D600 DOS       001C DOSS       E400 BIO       0000 PUBDRV    0000 PUBUSR

Figure 4.  For the technically inclined, this is a listing  of  the file
MINIMUM.NZC, which  describes  a minimum-size version of an NZCOM system
for the computer in Figs. 1 and 2.

------------------------------------------------------------------------

        A>nzcom /v
        NZCOM Ver 2.0 Copyright (C) 1987-88 Alpha Systems Corp 21 Jan 88
          Input buffer start 1C00
          Read  buffer start 1D00
          Write buffer start 3D00
          Loading A0:NZCOM.NZC
          Loading A0:NZCPR.REL for BD00 at 3D00
          Loading A0:NZDOS.REL for C500 at 4500
          Loading A0:NZBIO.REL for D300 at 5300
          Loading A0:NZIOP.REL for D400 at 5400
          Loading A0:NZRCP.REL for DA00 at 5A00
          Loading A0:NZFCP.REL for E200 at 6200
          Loading A0:NZCOM.NDR for E400 at 6400
          Loading A0:NZCOM.Z3T for E580 at 6580
          Writing A15:NZCOM.CCP
          Booting NZ-COM...

Figure 5.  This is the screen display  produced by NZCOM as it loads the
default system definition NZCOM.NZC with the verbose option.

------------------------------------------------------------------------

  Named COMMON declarations start here
  For compatibility, these are the same names used by Bridger Mitchell's
  JetLDR

        common  /_BIOS_/
CBIOS:                          ; Customer's BIOS address

        common  /_ENV_/
Z3ENV:                          ; Z3 Environment descriptor
Z3ENVS  EQU     2               ; Size (records)
RCP     EQU     Z3ENV+12
RCPS    EQU     YES             ; Used as existence test, not size
FCP     EQU     Z3ENV+18
FCPS    EQU     YES             ; Used as existence test, not size
Z3NDIR  EQU     Z3ENV+21
Z3NDIRS EQU     YES             ; Used as existence test, not size

DRVEC   EQU     Z3ENV+52        ; Valid drive vector

CCP     EQU     Z3ENV+63        ; CCP entry
CCPS    EQU     Z3ENV+65        ; Size

DOS     EQU     Z3ENV+66        ; DOS entry (+6)
DOSS    EQU     Z3ENV+68        ; Size

BIO     EQU     Z3ENV+69        ; BIO entry

        common  /_SSTK_/
SHSTK:                          ; Top of Shell stack
SHSTKS  EQU     4               ; 4 entries
SHSIZE  EQU     32              ; 32 bytes each

        common  /_MSG_/
Z3MSG:                          ; Message buffer
Z3MSGA  EQU     80              ; 80 bytes long

        common  /_FCB_/
EXTFCB:                         ; External file control block
EXTFCBS EQU     36              ; 36 bytes long
EXPATH  EQU     EXTFCB+EXTFCBS  ; External path
EXPATHS EQU     5               ; 5 elements
Z3WHL   EQU     EXPATH+(EXPATHS*2)+1 ; The wheel byte
Z3WHLS  EQU     1               ; 1 byte

        common  /_MCL_/
Z3CL:                           ; Multiple command line
Z3CLS   EQU     203             ; Maximum command length
ZZPAT   EQU     Z3CL+256        ; Potential User patch area

        common  /_XSTK_/
EXTSTK:                         ; External stack
EXTSKTS EQU     48              ; Size (bytes)

        CSEG                    ; Select Code Segment

  End of NZCMN.LIB

Figure 6.  This is a partial  listing  of  the file NZCMN.LIB, which de-
fines the named common blocks used during assembly of modules for use by
NZCOM.

------------------------------------------------------------------------

        B2:DBASE>nzcom minimum /v
        NZCOM Ver 2.0 Copyright (C) 1987-88 Alpha Systems Corp 21 Jan 88
          Input buffer start 1C00
          Read  buffer start 1D00
          Write buffer start 3D00
          Loading A0:MINIMUM.NZC
          Loading A0:NZCPR.REL for CE00 at 3D00
          Loading A0:NZDOS.REL for D600 at 4500
          Loading A0:NZBIO.REL for E400 at 5300
          Loading A0:NZCOM.Z3T for E580 at 5480
          Writing A15:NZCOM.CCP
          Booting NZ-COM...

Figure 7.  This is the screen display  when NZCOM loads the minimum sys-
tem from a running default system.

------------------------------------------------------------------------

        ; Beginning of program
        ;
        ENTRY:  DB      0C7H            ; RST 0  opcode,  will become JP
                DW      START
                DB      'Z3ENV'         ; ZCPR3 program ID
                DB      3               ; Type 3
        ;
        ENVADR: DW      0               ; ENV  address  filled in by Z34
                DW      ENTRY           ; Execution address
        ;
        START:                          ; Beginning of main program


Figure 8.  Form of the Z3ENV header  code in a protected type-3 program.
An attempt to execute this code under CP/M will result in  a  warm boot.

--------------------------------- end ----------------------------------
